In current mechanisms for application development, it is known to provide a development environment that enables a process to be mapped to and split between a plurality of parallel or concurrent execution paths or threads. The threading model confers the advantage that existing resources can be better utilized and that the computer time required for the process can be reduced.
If, for example, the process or part of the process entails transferring extensive medical image data from an input device to an image processing computer and performing inputs via a user interface with reference to said image data (e.g. captioning the images), then these are two fundamentally different tasks—on the one hand the data transmission and on the other hand the user input—which without a threading model can only be executed sequentially.
Consequently, the user input can only be performed once the entire data transmission process has been completed. This often results in unacceptable waiting times for the user. If, on the other hand, the threading model is used, it is possible for the user input to be performed already during the time in which the data is being transmitted, so that the two processes can be nested and/or executed in parallel in two different threads.
In general, a threading architecture requires increased programming effort however, among other things because hitherto it has been virtually impossible with the known methods from the prior art to exchange a subcomponent of a component containing a thread and replace it with another subcomponent. The previous procedure was highly inflexible in this respect.
Moreover, application development with multiple threads requires skilled software developers who know how to avoid classic threading anomalies. In application development systems to date, there has hitherto been no support nor a guided procedure with which the developer is provided with support in relation to the aforesaid problem areas.
If a threading model is used, among other things, the following problems must be taken into account:                it must be possible to generate and delete the respective threads or process sequences,        a synchronization of the access to and from different threads and        an assignment of computer resources for concurrent threads is necessary, and        communication mechanisms between threads must also be provided.        
If only one of the abovementioned problem areas is incorrectly or inadequately addressed during development with threads, the entire software project can fail.
Support for the application developer when using the threading model is hitherto unknown. On the contrary, it is necessary for developers to provide their own mechanisms for avoiding access errors, in particular ones based on an incorrect synchronization of the accesses to data of the different threads.
FIG. 1 shows the procedure for systems from the prior art which, although they provide for a plurality of threads, do not offer any automatic support for handling reciprocal accesses.
In principle, a plurality of parallel executing threads may be provided. Several components may run in one thread. From a component of one thread, it is possible to call a further component of another thread. The result of the call is usually solved via a callback from the called component to the calling component. The processing of such a callback from a called component to a calling component has hitherto been performed in the called component. This procedure made it necessary for application developers to manually generate new mechanisms for handling concurrent accesses to data of different threads for every process in each case.